Autogenerated HTML docs for v2.32.0-29-g211ec
diff --git a/RelNotes/2.33.0.txt b/RelNotes/2.33.0.txt new file mode 100644 index 0000000..6795a27 --- /dev/null +++ b/RelNotes/2.33.0.txt
@@ -0,0 +1,32 @@ +Git 2.33 Release Notes +====================== + +Updates since Git 2.32 +---------------------- + +UI, Workflows & Features + +Performance, Internal Implementation, Development Support etc. + + +Fixes since v2.31 +----------------- + + * We historically rejected a very short string as an author name + while accepting a patch e-mail, which has been loosened. + (merge 72ee47ceeb ef/mailinfo-short-name later to maint). + + * The parallel checkout codepath did not initialize object ID field + used to talk to the worker processes in a futureproof way. + + * Rewrite code that triggers undefined behaiour warning. + (merge aafa5df0df jn/size-t-casted-to-off-t-fix later to maint). + + * The description of "fast-forward" in the glossary has been updated. + (merge e22f2daed0 ry/clarify-fast-forward-in-glossary later to maint). + + * Other code cleanup, docfix, build fix, etc. + (merge bfe35a6165 ah/doc-describe later to maint). + (merge f302c1e4aa jc/clarify-revision-range later to maint). + (merge 3127ff90ea tl/fix-packfile-uri-doc later to maint). + (merge a84216c684 jk/doc-color-pager later to maint).
diff --git a/git-config.html b/git-config.html index a5de1fa..2650af0 100644 --- a/git-config.html +++ b/git-config.html
@@ -3765,8 +3765,9 @@ </dt> <dd> <p> - A boolean to enable/disable colored output when the pager is in - use (default is true). + A boolean to specify whether <code>auto</code> color modes should colorize + output going to the pager. Defaults to true; set this to false + if your pager does not understand ANSI color codes. </p> </dd> <dt class="hdlist1">
diff --git a/git-describe.html b/git-describe.html index 206ff9c..b136235 100644 --- a/git-describe.html +++ b/git-describe.html
@@ -840,9 +840,10 @@ </dt> <dd> <p> - Instead of using the default 7 hexadecimal digits as the - abbreviated object name, use <n> digits, or as many digits - as needed to form a unique object name. An <n> of 0 + Instead of using the default number of hexadecimal digits (which + will vary according to the number of objects in the repository with + a default of 7) of the abbreviated object name, use <n> digits, or + as many digits as needed to form a unique object name. An <n> of 0 will suppress long format, only showing the closest tag. </p> </dd> @@ -960,8 +961,11 @@ at the end.</p></div> <div class="paragraph"><p>The number of additional commits is the number of commits which would be displayed by "git log v1.0.4..parent". -The hash suffix is "-g" + unambiguous abbreviation for the tip commit -of parent (which was <code>2414721b194453f058079d897d13c4e377f92dc6</code>). +The hash suffix is "-g" + an unambigous abbreviation for the tip commit +of parent (which was <code>2414721b194453f058079d897d13c4e377f92dc6</code>). The +length of the abbreviation scales as the repository grows, using the +approximate number of objects in the repository and a bit of math +around the birthday paradox, and defaults to a minimum of 7. The "g" prefix stands for "git" and is used to allow describing the version of a software depending on the SCM the software is managed with. This is useful in an environment where people may use different SCMs.</p></div> @@ -1038,7 +1042,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2020-03-11 00:03:13 JST + 2021-06-10 12:50:35 JST </div> </div> </body>
diff --git a/git-describe.txt b/git-describe.txt index a88f6ae..c6a79c2 100644 --- a/git-describe.txt +++ b/git-describe.txt
@@ -63,9 +63,10 @@ Automatically implies --tags. --abbrev=<n>:: - Instead of using the default 7 hexadecimal digits as the - abbreviated object name, use <n> digits, or as many digits - as needed to form a unique object name. An <n> of 0 + Instead of using the default number of hexadecimal digits (which + will vary according to the number of objects in the repository with + a default of 7) of the abbreviated object name, use <n> digits, or + as many digits as needed to form a unique object name. An <n> of 0 will suppress long format, only showing the closest tag. --candidates=<n>:: @@ -139,8 +140,11 @@ The number of additional commits is the number of commits which would be displayed by "git log v1.0.4..parent". -The hash suffix is "-g" + unambiguous abbreviation for the tip commit -of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). +The hash suffix is "-g" + an unambigous abbreviation for the tip commit +of parent (which was `2414721b194453f058079d897d13c4e377f92dc6`). The +length of the abbreviation scales as the repository grows, using the +approximate number of objects in the repository and a bit of math +around the birthday paradox, and defaults to a minimum of 7. The "g" prefix stands for "git" and is used to allow describing the version of a software depending on the SCM the software is managed with. This is useful in an environment where people may use different SCMs.
diff --git a/git-rev-parse.html b/git-rev-parse.html index e6739d6..93b9366 100644 --- a/git-rev-parse.html +++ b/git-rev-parse.html
@@ -1668,6 +1668,8 @@ any of the given commits.</p></div> <div class="paragraph"><p>A commit’s reachable set is the commit itself and the commits in its ancestry chain.</p></div> +<div class="paragraph"><p>There are several notations to specify a set of connected commits +(called a "revision range"), illustrated below.</p></div> <div class="sect2"> <h3 id="_commit_exclusions">Commit Exclusions</h3> <div class="dlist"><dl> @@ -1718,6 +1720,26 @@ is a shorthand for <em>HEAD..origin</em> and asks "What did the origin do since I forked from them?" Note that <em>..</em> would mean <em>HEAD..HEAD</em> which is an empty range that is both reachable and unreachable from HEAD.</p></div> +<div class="paragraph"><p>Commands that are specifically designed to take two distinct ranges +(e.g. "git range-diff R1 R2" to compare two ranges) do exist, but +they are exceptions. Unless otherwise noted, all "git" commands +that operate on a set of commits work on a single revision range. +In other words, writing two "two-dot range notation" next to each +other, e.g.</p></div> +<div class="literalblock"> +<div class="content"> +<pre><code>$ git log A..B C..D</code></pre> +</div></div> +<div class="paragraph"><p>does <strong>not</strong> specify two revision ranges for most commands. Instead +it will name a single connected set of commits, i.e. those that are +reachable from either B or D but are reachable from neither A or C. +In a linear history like this:</p></div> +<div class="literalblock"> +<div class="content"> +<pre><code>---A---B---o---o---C---D</code></pre> +</div></div> +<div class="paragraph"><p>because A and B are reachable from C, the revision range specified +by these two dotted ranges is a single commit D.</p></div> </div> <div class="sect2"> <h3 id="_other_lt_rev_gt_94_parent_shorthand_notations">Other <rev>^ Parent Shorthand Notations</h3>
diff --git a/gitglossary.html b/gitglossary.html index a486745..8e9e053 100644 --- a/gitglossary.html +++ b/gitglossary.html
@@ -1005,8 +1005,8 @@ <a href="#def_revision">revision</a> and you are "merging" another <a href="#def_branch">branch</a>'s changes that happen to be a descendant of what you have. In such a case, you do not make a new <a href="#def_merge">merge</a> - <a href="#def_commit">commit</a> but instead just update to his - revision. This will happen frequently on a + <a href="#def_commit">commit</a> but instead just update your branch to point at the same + revision as the branch you are merging. This will happen frequently on a <a href="#def_remote_tracking_branch">remote-tracking branch</a> of a remote <a href="#def_repository">repository</a>. </p>
diff --git a/gitrevisions.html b/gitrevisions.html index f0cf521..f1e6b62 100644 --- a/gitrevisions.html +++ b/gitrevisions.html
@@ -1135,6 +1135,8 @@ any of the given commits.</p></div> <div class="paragraph"><p>A commit’s reachable set is the commit itself and the commits in its ancestry chain.</p></div> +<div class="paragraph"><p>There are several notations to specify a set of connected commits +(called a "revision range"), illustrated below.</p></div> <div class="sect2"> <h3 id="_commit_exclusions">Commit Exclusions</h3> <div class="dlist"><dl> @@ -1185,6 +1187,26 @@ is a shorthand for <em>HEAD..origin</em> and asks "What did the origin do since I forked from them?" Note that <em>..</em> would mean <em>HEAD..HEAD</em> which is an empty range that is both reachable and unreachable from HEAD.</p></div> +<div class="paragraph"><p>Commands that are specifically designed to take two distinct ranges +(e.g. "git range-diff R1 R2" to compare two ranges) do exist, but +they are exceptions. Unless otherwise noted, all "git" commands +that operate on a set of commits work on a single revision range. +In other words, writing two "two-dot range notation" next to each +other, e.g.</p></div> +<div class="literalblock"> +<div class="content"> +<pre><code>$ git log A..B C..D</code></pre> +</div></div> +<div class="paragraph"><p>does <strong>not</strong> specify two revision ranges for most commands. Instead +it will name a single connected set of commits, i.e. those that are +reachable from either B or D but are reachable from neither A or C. +In a linear history like this:</p></div> +<div class="literalblock"> +<div class="content"> +<pre><code>---A---B---o---o---C---D</code></pre> +</div></div> +<div class="paragraph"><p>because A and B are reachable from C, the revision range specified +by these two dotted ranges is a single commit D.</p></div> </div> <div class="sect2"> <h3 id="_other_lt_rev_gt_94_parent_shorthand_notations">Other <rev>^ Parent Shorthand Notations</h3>
diff --git a/glossary-content.txt b/glossary-content.txt index 67c7a50..c077971 100644 --- a/glossary-content.txt +++ b/glossary-content.txt
@@ -146,8 +146,8 @@ <<def_revision,revision>> and you are "merging" another <<def_branch,branch>>'s changes that happen to be a descendant of what you have. In such a case, you do not make a new <<def_merge,merge>> - <<def_commit,commit>> but instead just update to his - revision. This will happen frequently on a + <<def_commit,commit>> but instead just update your branch to point at the same + revision as the branch you are merging. This will happen frequently on a <<def_remote_tracking_branch,remote-tracking branch>> of a remote <<def_repository,repository>>.
diff --git a/howto/coordinate-embargoed-releases.html b/howto/coordinate-embargoed-releases.html index 2c036de..be5054a 100644 --- a/howto/coordinate-embargoed-releases.html +++ b/howto/coordinate-embargoed-releases.html
@@ -873,7 +873,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:58 JST + 2021-06-10 12:51:38 JST </div> </div> </body>
diff --git a/howto/keep-canonical-history-correct.html b/howto/keep-canonical-history-correct.html index b220260..ce3b80d 100644 --- a/howto/keep-canonical-history-correct.html +++ b/howto/keep-canonical-history-correct.html
@@ -938,7 +938,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:58 JST + 2021-06-10 12:51:37 JST </div> </div> </body>
diff --git a/howto/maintain-git.html b/howto/maintain-git.html index a2b46e5..4cf7f92 100644 --- a/howto/maintain-git.html +++ b/howto/maintain-git.html
@@ -1469,7 +1469,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:58 JST + 2021-06-10 12:51:38 JST </div> </div> </body>
diff --git a/howto/new-command.html b/howto/new-command.html index 60c64cf..29fcd27 100644 --- a/howto/new-command.html +++ b/howto/new-command.html
@@ -863,7 +863,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:55 JST + 2021-06-10 12:51:30 JST </div> </div> </body>
diff --git a/howto/rebase-from-internal-branch.html b/howto/rebase-from-internal-branch.html index d7547c5..57653ef 100644 --- a/howto/rebase-from-internal-branch.html +++ b/howto/rebase-from-internal-branch.html
@@ -895,7 +895,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:58 JST + 2021-06-10 12:51:37 JST </div> </div> </body>
diff --git a/howto/rebuild-from-update-hook.html b/howto/rebuild-from-update-hook.html index 848e256..53c8b36 100644 --- a/howto/rebuild-from-update-hook.html +++ b/howto/rebuild-from-update-hook.html
@@ -847,7 +847,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:58 JST + 2021-06-10 12:51:36 JST </div> </div> </body>
diff --git a/howto/recover-corrupted-blob-object.html b/howto/recover-corrupted-blob-object.html index c731b45..76be39f 100644 --- a/howto/recover-corrupted-blob-object.html +++ b/howto/recover-corrupted-blob-object.html
@@ -880,7 +880,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:57 JST + 2021-06-10 12:51:36 JST </div> </div> </body>
diff --git a/howto/recover-corrupted-object-harder.html b/howto/recover-corrupted-object-harder.html index ad31903..628cc2a 100644 --- a/howto/recover-corrupted-object-harder.html +++ b/howto/recover-corrupted-object-harder.html
@@ -1189,7 +1189,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:58 JST + 2021-06-10 12:51:36 JST </div> </div> </body>
diff --git a/howto/revert-a-faulty-merge.html b/howto/revert-a-faulty-merge.html index 9f52f70..8f39ee4 100644 --- a/howto/revert-a-faulty-merge.html +++ b/howto/revert-a-faulty-merge.html
@@ -1025,7 +1025,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:57 JST + 2021-06-10 12:51:35 JST </div> </div> </body>
diff --git a/howto/revert-branch-rebase.html b/howto/revert-branch-rebase.html index fd61fb0..b62848b 100644 --- a/howto/revert-branch-rebase.html +++ b/howto/revert-branch-rebase.html
@@ -907,7 +907,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:55 JST + 2021-06-10 12:51:31 JST </div> </div> </body>
diff --git a/howto/separating-topic-branches.html b/howto/separating-topic-branches.html index c65a2f2..9eec17b 100644 --- a/howto/separating-topic-branches.html +++ b/howto/separating-topic-branches.html
@@ -841,7 +841,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:57 JST + 2021-06-10 12:51:34 JST </div> </div> </body>
diff --git a/howto/setup-git-server-over-http.html b/howto/setup-git-server-over-http.html index ffc1ac8..a7abf6a 100644 --- a/howto/setup-git-server-over-http.html +++ b/howto/setup-git-server-over-http.html
@@ -1071,7 +1071,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:57 JST + 2021-06-10 12:51:34 JST </div> </div> </body>
diff --git a/howto/update-hook-example.html b/howto/update-hook-example.html index 0d6635d..7c43993 100644 --- a/howto/update-hook-example.html +++ b/howto/update-hook-example.html
@@ -930,7 +930,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:56 JST + 2021-06-10 12:51:33 JST </div> </div> </body>
diff --git a/howto/use-git-daemon.html b/howto/use-git-daemon.html index 1715b45..2929dc4 100644 --- a/howto/use-git-daemon.html +++ b/howto/use-git-daemon.html
@@ -791,7 +791,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:56 JST + 2021-06-10 12:51:33 JST </div> </div> </body>
diff --git a/howto/using-merge-subtree.html b/howto/using-merge-subtree.html index fbd0891..4083a82 100644 --- a/howto/using-merge-subtree.html +++ b/howto/using-merge-subtree.html
@@ -848,7 +848,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:56 JST + 2021-06-10 12:51:31 JST </div> </div> </body>
diff --git a/howto/using-signed-tag-in-pull-request.html b/howto/using-signed-tag-in-pull-request.html index 2ae598f..36b9f7a 100644 --- a/howto/using-signed-tag-in-pull-request.html +++ b/howto/using-signed-tag-in-pull-request.html
@@ -952,7 +952,7 @@ <div id="footer"> <div id="footer-text"> Last updated - 2021-06-06 17:01:56 JST + 2021-06-10 12:51:32 JST </div> </div> </body>
diff --git a/revisions.txt b/revisions.txt index d9169c0..f5f17b6 100644 --- a/revisions.txt +++ b/revisions.txt
@@ -260,6 +260,9 @@ A commit's reachable set is the commit itself and the commits in its ancestry chain. +There are several notations to specify a set of connected commits +(called a "revision range"), illustrated below. + Commit Exclusions ~~~~~~~~~~~~~~~~~ @@ -294,6 +297,26 @@ I forked from them?" Note that '..' would mean 'HEAD..HEAD' which is an empty range that is both reachable and unreachable from HEAD. +Commands that are specifically designed to take two distinct ranges +(e.g. "git range-diff R1 R2" to compare two ranges) do exist, but +they are exceptions. Unless otherwise noted, all "git" commands +that operate on a set of commits work on a single revision range. +In other words, writing two "two-dot range notation" next to each +other, e.g. + + $ git log A..B C..D + +does *not* specify two revision ranges for most commands. Instead +it will name a single connected set of commits, i.e. those that are +reachable from either B or D but are reachable from neither A or C. +In a linear history like this: + + ---A---B---o---o---C---D + +because A and B are reachable from C, the revision range specified +by these two dotted ranges is a single commit D. + + Other <rev>{caret} Parent Shorthand Notations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Three other shorthands exist, particularly useful for merge commits, diff --git a/technical/packfile-uri.txt b/technical/packfile-uri.txt index f7eabc6..1eb525f 100644 --- a/technical/packfile-uri.txt +++ b/technical/packfile-uri.txt
@@ -35,13 +35,14 @@ at least so that we can test the client. This is the implementation: a feature, marked experimental, that allows the -server to be configured by one or more `uploadpack.blobPackfileUri=<sha1> -<uri>` entries. Whenever the list of objects to be sent is assembled, all such -blobs are excluded, replaced with URIs. As noted in "Future work" below, the -server can evolve in the future to support excluding other objects (or other -implementations of servers could be made that support excluding other objects) -without needing a protocol change, so clients should not expect that packfiles -downloaded in this way only contain single blobs. +server to be configured by one or more `uploadpack.blobPackfileUri= +<object-hash> <pack-hash> <uri>` entries. Whenever the list of objects to be +sent is assembled, all such blobs are excluded, replaced with URIs. As noted +in "Future work" below, the server can evolve in the future to support +excluding other objects (or other implementations of servers could be made +that support excluding other objects) without needing a protocol change, so +clients should not expect that packfiles downloaded in this way only contain +single blobs. Client design -------------
diff --git a/user-manual.html b/user-manual.html index 90da315..676562d 100644 --- a/user-manual.html +++ b/user-manual.html
@@ -2113,8 +2113,8 @@ <a class="link" href="#def_revision">revision</a> and you are "merging" another <a class="link" href="#def_branch">branch</a>'s changes that happen to be a descendant of what you have. In such a case, you do not make a new <a class="link" href="#def_merge">merge</a> - <a class="link" href="#def_commit">commit</a> but instead just update to his - revision. This will happen frequently on a + <a class="link" href="#def_commit">commit</a> but instead just update your branch to point at the same + revision as the branch you are merging. This will happen frequently on a <a class="link" href="#def_remote_tracking_branch">remote-tracking branch</a> of a remote <a class="link" href="#def_repository">repository</a>. </dd><dt><span class="term">
